Moves mcp-json API back into mcp-core for simplified dependencies and support of osgi runtimes#762
Conversation
…n API back into mcp-core so that mcp-json API is no longer needed and mcp-core has fewer dependencies.
mcp-core/src/main/java/io/modelcontextprotocol/util/McpServiceLoader.java
Outdated
Show resolved
Hide resolved
mcp-core/src/main/java/io/modelcontextprotocol/json/McpJsonDefaults.java
Show resolved
Hide resolved
mcp-core/src/main/java/io/modelcontextprotocol/json/internal/DefaultMcpJsonMapperSupplier.java
Outdated
Show resolved
Hide resolved
…Loader.java Co-authored-by: Luca Chang <131398524+LucaButBoring@users.noreply.github.com>
and DefaultMcpJsonSchemaSupplier as they were originally committed accidently. Thanks to LucaButBoring for pointing out the error.
…cp-java-sdk into issue_612_jackson3
|
@scottslewis, I'm not familiar with OSGi that much, but I have some general questions about the PR.
|
I could have...but chose to leave it so that the pr was not as large. If doing it in one step is preferable then that can be done.
The impl of McpJsonDefaults is key to working (for json defaults) in non osgi and osgi environments. In non osgi environments, the serviceloader is used to find and load jackson2 or jackson3 impl for defaults as done previously. In osgi, the serviceloader does not work the same...because of classloader-per-bundle as per osgi issue #562. In osgi, mcpjsondefaults is created and configured on start by the osgi sevice registry using scr metadata in manifests. For clarity here is the McpJsonDefaults scr metadata |
|
Thanks for the explanation @scottslewis, always good to learn a bit more about it.
I think the PR would actually be smaller then, since the classes that are removed, they'll show up as modified moved in git with no changes. |
Ok, honestly I don't care that much. Let's get the code and build/test/dependency changes reviewed/complete/consensus, etc...without breaking the build and test/CI if possible...and I'll delete or someone else can...whatever the choice is fine by me. |
| mcpMapperServiceLoader.unsetSupplier(supplier); | ||
| } | ||
|
|
||
| public synchronized static McpJsonMapper getDefaultMcpJsonMapper() { |
There was a problem hiding this comment.
[issue] There are two separate synchronized methods, each using constructor side-effects. My understanding is that the synchronized is to avoid calling the constructor twice. If that's the case, in the current state, calling both methods at the same time triggers a race condition.
| @@ -0,0 +1,50 @@ | |||
| package io.modelcontextprotocol.json; | |||
| import io.modelcontextprotocol.json.schema.JsonSchemaValidatorSupplier; | ||
| import io.modelcontextprotocol.util.McpServiceLoader; | ||
|
|
||
| public class McpJsonDefaults { |
There was a problem hiding this comment.
The patterns used here are uncommon in non-OSGi codebases. Please add a note in the javadoc mentioning OSGi compatibility.
| @@ -0,0 +1,50 @@ | |||
| package io.modelcontextprotocol.util; | |||
| import java.util.ServiceLoader; | ||
| import java.util.function.Supplier; | ||
|
|
||
| public class McpServiceLoader<S extends Supplier<R>, R> { |
There was a problem hiding this comment.
Same as McpJsonDefaults, mention OSGi here.
| // Use serviceloader | ||
| Optional<?> sl = serviceLoad(this.supplierType); | ||
| if (sl.isEmpty()) { | ||
| throw new ServiceConfigurationError("No %s available for creating McpJsonMapper".format(this.supplierType.getSimpleName())); |
There was a problem hiding this comment.
Did you mean to use "...".formatted(...), or String.format("...", ...) ?
@scottslewis Happy to help collaborating with @Kehrlann to get this PR merged, but please squash/rework the commits to have files moved instead of copied as suggested by @filiphr, otherwise the diff is useless and the signal/noise ratio horrible. We do strongly care about that as reviewers, thanks for your understanding. |
mcp-core so that mcp-json API is no longer needed and mcp-core has fewer dependencies.
See issue #612 and previous pr #682
Motivation and Context
Simplifies dependency structure, and reenables ability to use OSGi runtimes #562
How Has This Been Tested?
Have tested in OSGi environments running OSGi application.
Breaking Changes
This eliminates the need to deploy mcp-json jar, meaning that users will only have to (minimally) deploy mcp-core and either mcp-json-jackson2 or mcp-json-jackson3
Types of changes
Checklist
Additional context
To deal with the testing dependencies issues as described here: #682 (comment)
it may be necessary to add further changes/refactoring/moving of the test code (in mcp-core specifically). I'm willing to do or contribute to this refactoring if needed, once consensus is achieved.